Determining a location related to on-demand services through use of portable computing devices

ABSTRACT

A method for determining a location relating to an on-demand service on a computing device is provided. One or more processors receiving a transport request from a user. The transport request specifies at least one of a pick-up region or a drop-off region. One or more locations of interests within the at least one of the pick-up region or the drop-off region are determined. Based on the at least one of the pick-up region or the drop-off region, one or more historical locations related to the user is determined. A likely location is determined based on the determined one or more locations of interest and the one or more historical locations.

RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 12/961,493, filed Dec. 6, 2010, entitled “System and Method forArranging Transport Amongst Parties Through Use of Mobile Devices,”which claims benefit of priority to Provisional U.S. Patent ApplicationNo. 61/266,996, filed Dec. 4, 2009; the aforementioned applicationsbeing incorporated by reference in their entirety.

TECHNICAL FIELD

Embodiments described herein pertain generally to a system and methodfor providing on-demand services through use of portable computingdevices.

BACKGROUND

Current on-demand services, such as fleet management systems employedfor Taxi and limousine fleets, typically utilize onboard meteringdevices, radios, and cell phones to dispatch drivers and monitor fares.Such systems typically are not communicative to customers that arewaiting for pickup. In addition, although some on-demand services useposition information provided by computing devices of customers inrelation to providing services, the global positioning system (GPS) dataprovided by a computing device may not necessarily be accurate due tocomponent defects or signal interference (e.g., typically in urbanareas).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system for enabling a user to requeston-demand services using a computing device, under an embodiment.

FIG. 2 illustrates an example method for enabling a user to requeston-demand services using a computing device, according to an embodiment.

FIGS. 3A-3H illustrate examples of user interfaces that are displayed toa user to enable the user to request an on-demand service, according toan embodiment.

FIGS. 4A-4C illustrate examples of user interfaces that are displayed toa user to enable the user to select a pickup location for an on-demandservice, under another embodiment.

FIG. 5 illustrates an example method for determining a location relatedto an on-demand service request, under an embodiment.

FIGS. 6A-6B illustrate examples of confirmation user interfaces that aredisplayed to a user when an on-demand service has been requested,according to an embodiment.

FIGS. 7A-7B illustrate examples of fare information panels that provideadditional information about a fare for an on-demand service, under anembodiment.

FIGS. 8A-8D illustrate an example series of user interfaces that aredisplayed to a user to provide additional content for various on-demandservices, under an embodiment.

FIG. 9 is a block diagram that illustrates a mobile computing deviceupon which embodiments described herein may be implemented.

DETAILED DESCRIPTION

Embodiments described herein provide an interactive environment forenabling a user to request on-demand services using a computing device.In particular, some embodiments described herein enable mobile computingdevices, such as smart phones and geo-aware cellular telephony devices,to be used in connection with an on-demand service that enables the userto request services, such as a delivery service or transport service,using a simplified user interface schematic. Functionality, such ascommunicating the location of the user, the location of availableservice providers, the types of service available, the estimated feesand other information, can be aggregated and provided to the user in anefficient and user-friendly manner.

In one embodiment, a computing device can operate an application forrequesting on-demand services. The application can provide userinterface features that provide a user of the application withinformation for enabling the user to request a particular type ofservice. For example, the user can be provided a mechanism for selectingservices and service types, as well as displaying information that mayaffect the decision of the user in making such selections.

According to some embodiments, the information and service options madeavailable to the user can be region-specific. For example, differenton-demand services and information about different services can beprovided to the user based on the region that the user is located in.Thus, the service options made available to the user, as well as theinformation provided to the user regarding the service options can bemade region specific.

In some embodiments, different user interface features can be provided,at least in part, by an application or program that is stored andoperated on the user's computing device. The application can beconfigured to communicate with an on-demand service system that arrangesservices between users and service providers (e.g., drivers fortransport, ice cream delivery providers, personal telegram serviceproviders, etc.). For example, a user can request food to be deliveredto his or her office, and the on-demand service system can determineavailable food providers that satisfy the user's request and arrange fora food provider to perform the service. The user is enabled, via theuser interface features, to make different selections for viewingspecified information and for requesting different on-demand serviceoptions based on the user selections.

According to an embodiment, a location of the computing device can bedetermined so that user interface features for requesting an on-demandservice can be presented, on a display of the computing device, based onthe device's real-time location. A multistate selection feature can beprovided to enable a user to select a particular type of service. In oneimplementation, the multistate selection feature identifies a pluralityof service options for an on-demand service (e.g., types of vehiclesthat can provide a transport service for the user, types of food trucks,delivery methods, etc.), based on a region where the user is located(e.g. the device's real-time location).

In one embodiment, a summary user interface can be presented on thedisplay in response to the user selecting one of the plurality of theservice options, such as a vehicle type for a delivery or transport, ortype of food service. The summary user interface can includeregion-specific information about the on-demand service that isparticular to and based on the selected service option. For example, foran on-demand food service, the summary user interface can includeregion-specific information about the closest food service providers,types of foods available in the region, average prices for the foods,the inventory available, etc. In another example, the region-specificinformation can include an estimated time of arrival to the user'scurrent location, the average price, the amount of space/capacity of thevehicle, etc. The provided information can assist the user in making abetter informed decision in requesting the on-demand service. In someimplementations, the user can interact with the multistate selectionfeature by selecting different service types or service options to causethe contents within the summary user interface to dynamically changeaccordingly.

When a user makes a service request, the user can specify a location orregion related to the service request. In one example, for a transportservice request, the user can specify a pick-up location or regionand/or a drop-off location or region via one or more user interfacefeatures provided by a service application. Based on the specifiedregion, the service application and/or the on-demand service system candetermine one or locations of interests and locations related to theuser. The service application and/or the on-demand service system canuse the determined locations in order to determine a likely location forthe user.

Still further, in some embodiments, once the user requests the on-demandservice based on the selected service option, a confirmation userinterface feature can be displayed to present additional features andinformation that the user can verify before confirming the request. Whenthe user confirms the request (e.g., places an order), the computingdevice can provide the service request to the on-demand service systemwith necessary user data so that the on-demand service system canarrange the service between the user and an available service provider.The user can provide additional information on the confirmation userinterface feature, such as, for example, special notes for the serviceprovider or a promotional code before confirming the request.

As described herein, a “user,” or a “customer” refer to individuals thatare requesting or ordering an on-demand service. Also as describedherein, a “provider,” or a “service provider” refer to individuals orentities that can provide the requested service. As an example, a usercan request an on-demand service (e.g., car/Taxi service, food delivery,messenger service, telegram service, or provide a product) using thesystem, and a service provider can communicate with the system and/orthe user to arrange to perform the service. In addition, as describedherein, “customer devices” and “provider devices” refer to computingdevices that can correspond to desktop computers, cellular orsmartphones, personal digital assistants (PDAs), laptop computers,tablet devices, television (IP Television), etc., that can providenetwork connectivity and processing resources for enabling a user tocommunicate with a system over a network. A provider device can alsocorrespond to taxi meters or other metering devices.

One or more embodiments described herein provide that methods,techniques, and actions performed by a computing device are performedprogrammatically, or as a computer-implemented method. Programmatically,as used herein, means through the use of code or computer-executableinstructions. These instructions can be stored in one or more memoryresources of the computing device. A programmatically performed step mayor may not be automatic.

One or more embodiments described herein can be implemented usingprogrammatic modules, engines, or components. A programmatic module,engine, or component can include a program, a sub-routine, a portion ofa program, or a software component or a hardware component capable ofperforming one or more stated tasks or functions. As used herein, amodule or component can exist on a hardware component independently ofother modules or components. Alternatively, a module or component can bea shared element or process of other modules, programs or machines.

Some embodiments described herein can generally require the use ofcomputing devices, including processing and memory resources. Forexample, one or more embodiments described herein may be implemented, inwhole or in part, on computing devices such as servers, desktopcomputers, cellular or smartphones, personal digital assistants (e.g.,PDAs), laptop computers, printers, digital picture frames, networkequipments (e.g., routers) and tablet devices. Memory, processing, andnetwork resources may all be used in connection with the establishment,use, or performance of any embodiment described herein (including withthe performance of any method or with the implementation of any system).

Furthermore, one or more embodiments described herein may be implementedthrough the use of instructions that are executable by one or moreprocessors. These instructions may be carried on a computer-readablemedium. Machines shown or described with figures below provide examplesof processing resources and computer-readable mediums on whichinstructions for implementing embodiments of the invention can becarried and/or executed. In particular, the numerous machines shown withembodiments of the invention include processor(s) and various forms ofmemory for holding data and instructions. Examples of computer-readablemediums include permanent memory storage devices, such as hard drives onpersonal computers or servers. Other examples of computer storagemediums include portable storage units, such as CD or DVD units, flashmemory (such as carried on smartphones, multifunctional devices ortablets), and magnetic memory. Computers, terminals, network enableddevices (e.g., mobile devices, such as cell phones) are all examples ofmachines and devices that utilize processors, memory, and instructionsstored on computer-readable mediums. Additionally, embodiments may beimplemented in the form of computer-programs, or a computer usablecarrier medium capable of carrying such a program.

System Description

FIG. 1 illustrates an example on-demand service user interface system,under an embodiment. According to some embodiments, system 100 can beimplemented through software that operates on a portable computingdevice, such as a mobile computing device 180. System 100 can beconfigured to communicate with one or more network services thatcoordinate or otherwise provide on-demand services. Additionally, themobile computing device can include inherent or native functionality,and can utilize third-party services which enable further functionalitythrough system 100.

As an alternative or addition, some or all of the components of system100 can be implemented on one or more computing devices, such as on oneor more servers or other mobile computing devices. System 100 can alsobe implemented through other computer systems in alternativearchitectures (e.g., peer-to-peer networks, etc.). Accordingly, system100 can use data provided by an on-demand service system, data providedby other components of the mobile computing device, and informationprovided by a user in order to present user interface features andfunctionality for enabling the user to request an on-demand service. Theuser interface features can be specific to the location or region thatthe computing device is located in, so that region-specific informationcan be provided to the user. System 100 can also adjust the userinterface features, including the content displayed as part of the userinterface features, based on other user selections.

In some implementations, system 100 includes an on-demand serviceapplication 110, a map component 140, a map database 143, and a locationdetermination 145. The components of system 100 can combine to provideuser interface features that are specific to user selections, userlocality, and/or real-time conditions to enable a user to requeston-demand services. The on-demand service application 110 can correspondto a program that is downloaded onto a smartphone, portable computerdevice (e.g., tablet or other ego-aware device). In one implementation,a user can download and install the on-demand service application 110 onhis or her computing device and register the computing device 180 withan on-demand service system of the entity.

The on-demand service application 110 can include an application manager115, a user interface (UI) component 120, and a service interface 125.The service interface 125 can be used to handle communications exchangedbetween the on-demand service application 110 and the on-demand servicesystem 170 (e.g., over a network). For example, the service interface125 can use one or more network resources of the device 180 forexchanging communications over a wireless network. The network resourcescan include, for example, a cellular data/voice interface to enable thedevice to receive and send network communications over a cellulartransport. As an alternative or variation, the network resources caninclude a wireless network interface for connecting to access points(e.g., Wireless Fidelity 802.11(g) or 802.11(n)) or for using othertypes of wireless mediums (e.g., WiMax)

The application manager 115 can receive user input 111, locationinformation 147, and other information (such as user information 151and/or historical information 153) to configure content that is to beprovided by the UI component 120. For example, the UI component 120 cancause various user interface features 121 to be output to a display ofthe computing device 180. Some of the user interface features 121 can beregion-specific (e.g., based on the current location of the computingdevice) to display information that is particular to the region. Theuser interface features 121 can also provide dynamically adjustedcontent based on user selections provided via the user input 111.

For example, the UI component 120 uses a UI framework that can beconfigured with various content, such as UI content 175 provided by theon-demand service system 170 and content as a result of user input. TheUI component 120 can also configure the UI framework with locationinformation 147 and map content 141. In this manner, a map of a regionin which the user is currently located in can be displayed as part of auser interface feature 121. In some examples, the map component 140 canprovide the map content 141 using map data stored in one or more mapdatabases 143. Based on the locale of the user and the user selection(s)made for requesting an on-demand service, such as a type of food or atype of vehicle that the user would like to be transported in, theapplication manager 115 can cause region-specific anduser-selection-specific UI content 175 to be presented with or as partof a user interface 121.

In some implementations, the user interfaces 121 can be configured bythe application manager 115 to display information about on-demandservices that are available for the user-specific region. On-demandservices can include food services (e.g., users can order food, requestmobile food providers such as food trucks, request dessert providerssuch as ice cream trucks), delivery services, transport services,telegram or entertainment services (e.g., users can request mariachibands, singing quartets), or other services that the user can requestvia the on-demand service system. Based on the user's region, differentservices and service options can be available for the user.

For example, for an on-demand transport service, Taxicab vehicles may beavailable in one city, and unavailable in another. Similarly, a hybridvehicle may be available in one city, and unavailable in another. Inanother example, for an entertainment service, an on-demand Mariachiband may be available in one country or region, and may not be availablein other countries. In various examples described, the user interfaces121, which displays information about services available for a user, aswell as features to enable the user to request services, can beconfigured with network user interface content (e.g., provided by theon-demand service system 170) to reflect the services available to theuser based on the user's geographic region. The user is enabled tointeract with the different displayed user interface features 121, viathe user input 111, to make selections and input preferences whenrequesting an on-demand service from the on-demand service system 170.

When the on-demand service application 110 is operated by the user, thevarious user interfaces 121 can be rendered to the user based on theuser inputs 111 and/or information received from the on-demand servicesystem 170. These user interfaces include, for example, a home page userinterface (e.g., an initial page or launch page), a multistate selectionfeature, a summary user interface, a location suggestion user interface,a location search user interface, a confirmation user interface, or acombination of any of the features described. For example, the UIcomponent 120 can cause a home page user interface 121 to be displayedthat identifies the service(s) that the user can request using theon-demand service application 110. The home page user interface 121 canalso provide only certain service selection options or types that areavailable in the user's region. In this manner, based on the currentlocation of the computing device, the on-demand service application 110can cause location-specific user interfaces 121 and content to bepresented to the user.

In many instances, a geographic region that is specific to the user canbe based on the user's current location (e.g., the current location ofthe computing device 180) or the user's requested service location(e.g., the pickup location for a transport service, or a deliverylocation for a food service). For example, in some cases, the currentlocation can be different from the requested service location, so thatthe user can manually select a particular pickup location or deliverylocation that is different from the current location of the computingdevice 180. The user's current location or service performance locationcan be determined by the location determination 145.

The location determination 145 can determine the location of thecomputing device in different ways. In one example, the locationdetermination 145 can receive global positioning system (GPS) data 161from location-based/geo-aware resources 160 of the computing device 180.In addition, the location determination 145 can also receive GPS data161 from other applications or programs that operate on the computingdevice 160. For example, system 100 can communicate with one or moreother applications using one or more application program interfaces(APIs). The on-demand service application 110 can use the locationinformation 147 to cause the UI component 120 to configure the UIframework based on the location information 147. In addition, theon-demand service application 110 can provide the user's location data119 to the on-demand service system 170.

As an addition or alternative, the on-demand service application 110and/or the on-demand service system 170 can determine the user's currentlocation, pickup location, and/or drop-off location (i) by usinglocation data 177 provided by the on-demand service system 170, (ii) byusing user location input provided by the user (via a user input 111),and/or (iii) by using user info 151 and/or historical info 153 stored inone or more user databases 150. For example, the user can provide aninput 111 specifying a pickup region or a drop-off region by interactingwith a map on a user interface of the on-demand service application. Insome cases, the input 111 can specify a general region (as opposed to aparticular address). In such cases, the service application 110 and/orthe on-demand service system 170 can attempt to pin-point a more preciselocation for the user.

For example, the on-demand service application 110 and/or the on-demandservice system 170 can cross-reference the location data 119 (receivedfrom the on-demand service application 110) with the other sources ordatabases (e.g., third party servers and systems) that maintain locationinformation to obtain granular/specific data about the particularidentified location. In some cases, by cross-referencing the data, witha business directory, for example the on-demand service system 170 canidentify particular stores, restaurants, apartment complexes, venues,street addresses, etc., that are proximate to and/or located at theidentified location, and provide this information as location data 177to the on-demand service application 110. The application manager 115can cause the UI component 120 to provide the specific locationinformation as part of the user interface 121 so that the user canselect a particular store or venue as the current location or theservice performance location (e.g., a pick up location or deliverylocation).

The on-demand service application 110 can also receive user locationinput provided by the user to determine the current location or servicelocation of the user. In one example, the on-demand service application110 can cause the UI component 120 to present a location search userinterface on the display. The user can input a search term to identifystores, restaurants, venues, addresses, etc., that the user wishes torequest the on-demand service. The on-demand service application 110 canperform the search by querying one or more external sources to providethe search results to the user. In some variations, the user canmanually provide user location input by entering an address (e.g., witha number, street, city, state) or by manipulating and moving a servicelocation graphic/icon on a map that is displayed as part of a userinterface 121. In response to the user selection, the on-demand serviceapplication 110 can provide the location data 119 to the on-demandservice system 170.

In another variation, the on-demand service application 110 can retrieveand use user information 151 and/or historical information 153 that arestored in a user database 150. The user database 150 can include recordsof the user's previous on-demand service requests as well as userpreferences. In some implementations, the user database 150 can bestored remotely at the on-demand service system 170 and user informationcan be retrieved from the on-demand service system 170. The on-demandservice application 110 can use the data stored in the user database 150to identify previous service locations for the user (e.g., a BBQsandwiches food ordering application 110 can access the user database150 for records of when the user ordered food and where the food wasdelivered to). Based, in part, on the current location of the computingdevice 180, the on-demand service application 110 can use the userinformation 151, such as the user's home address, the user's place ofbusiness, the user's preferences, etc., and historical information 153,such as the frequency and recency of previous locations that the userrequested services at, to provide recent and/or recommended points ofinterest to the user. When the user selects one of the entries of arecommended point of interest as a current location and/or pickuplocation, the on-demand service application 110 can provide the locationdata 119 to the on-demand service system 170.

Based on the user's current location or service location, theapplication manager 115 can cause region-specific user interfacefeatures 121 to be outputted by the UI component 120. A region that isspecific to the user includes the current location (or service location)in which on-demand services can be provided to the user. The region canbe a city or metropolitan area in which the computing device 180 iscurrently located in, can be an area having a predetermined distanceradius from current location (e.g., six miles), or can be an area thatis specifically partitioned from other areas. Based on the user'sregion, the application manager 115 can cause region-specificinformation about the on-demand service to be provided on one or moreuser interface features 121.

Region-specific information about the on-demand service can be provided,in part, by the on-demand service system 170. As discussed, theon-demand service application 110 can provide location information tothe on-demand service system 170 so that the on-demand service system170 can arrange for a service to be provided to a user (e.g., arrange atransport service or an entertainment provider service). Based on theuser-specified region, the on-demand service system 170 can provideinformation about available service providers (e.g., drivers, ormariachi bands) that can perform the on-demand service in that region.

For example, for a transport service, a transport on-demand servicesystem 170 can maintain information about the number of availablevehicles, the number of available drivers, which drivers are currentlyperforming a transport service, which drivers are ready to pick upusers, the current location of the vehicles, the direction anddestination of the vehicles in motion, etc., in order to properlyarrange the transport service between users and drivers. In anotherexample, for a food service, a food on-demand service system 170 canmaintain information about the different food trucks that are available,where the food trucks are, how long a food truck will be at a particularlocation, what type of foods are being served, etc. Because services canvary between regions, such as cities, the application manager 115 cancause only information pertinent to the user's specific region to beprovided as part of the user interface 121.

Using the information maintained about the services and the serviceproviders, the on-demand service system 170 can provide relevantinformation to the on-demand service application 110. Serviceinformation 171 can correspond to information about the particularon-demand service that can be arranged by the on-demand service system170 (e.g., food services, delivery services, transport services,telegram or entertainment services). Service information 171 can includeinformation about costs for the service, available service options(e.g., types of food available, types of entertainment, deliveryoptions), or other details (e.g., available times, specials, etc.).Provider information 173 can correspond to information about theavailable service providers themselves, such as profile informationabout the providers, the current location or movement of the deliveryvehicles, transport vehicles, food trucks, etc., or the types ofvehicles.

Referring back to the example of an on-demand transport service, if theuser requests pickup in San Francisco, Calif., the on-demand servicesystem 170 would look for available drivers within a particular distanceor particular pickup time from the user (e.g., the system would notconsider drivers in Los Angeles, Calif.). The on-demand service system170 can transmit relevant service information 171 (e.g., cost for theservice, promotions in the area) and relevant provider information 173(e.g., driver information, vehicle information) to the on-demand serviceapplication 110 so that the on-demand service application 110 can causeregion-specific information to be presented to the user. For any type ofon-demand service, the on-demand service system 170 can transmit serviceinformation 171 and/or service provider information 173 to the on-demandservice application 110.

As an example, a region-specific user interface feature 121 can includea multistate selection panel. The multistate selection panel can includea multistate selection feature that can be manipulated and moved by theuser (e.g., by interacting with an input mechanism or a touch-sensitivedisplay screen) in order to select one or more service options torequest the on-demand service. Based on the user's determined region,the multistate selection panel can identify and display only certainoptions that are available for providing the on-demand service in thatregion. For an on-demand transport service, for example, if limousinesor SUVs are unavailable in a particular region, such as San Francisco,but Taxis, Sedans, and hybrid vehicles are available, the multistateselection panel can enable only the available vehicle types to bedisplayed and/or selected by the user. The indicators for theunavailable types of vehicles, such as limousines and SUVs, for example,can be blocked out, hidden, or displayed in a different manner thanindicators for vehicle types that are available in that region.

Similarly, in an example for on-demand dessert, the multistate selectionpanel can provide different dessert types that are available forselection by a user in the region. If ice cream is unavailable for aparticular region, while tarts, cookies, or cheesecakes are availablefor a user to request, the multistate selection panel can enable onlytarts, cookies, or cheesecakes to be selected by the user in requestingthe on-demand dessert service.

When the user interacts with the multistate selection feature,additional information corresponding to the selected service option canbe provided in a region-specific user interface feature 121. In oneimplementation, the user interface feature 121 can correspond to asummary panel that displays region-specific information about theselected service option. For example, for an on-demand food or dessertservice, once a user makes a selection of a type of service (e.g., atype of food or a certain food truck, etc.), the summary panel candisplay information about the closest available food provider, theaverage cost for an order, menu details, service provider profileinformation, or other information that the user can quickly view to makean informed decision.

In another example, for an on-demand transport service, the summarypanel can provide region-specific information, such as the estimatedtime of arrival for pickup (based on the user's current location orpickup location and the current locations of the available vehicles ofthe selected type), the average fare based on the region (e.g., theaverage estimated fare can be region-specific because some regions canbe more expensive than other regions and/or some vehicle types can bemore expensive than other vehicle types), and the capacity of thevehicle (how many riders can fit in the vehicle). In one variation, thesummary panel can be provided concurrently with the multistate selectionpanel so that when the user manipulates the multistate selection featureto select different service options, the content within the summarypanel can be dynamically adjusted by the on-demand service application110 to provide updated information corresponding to the selected option.

Once the user makes a selection by providing a user input 111, theapplication manager 115 can cause the UI component 120 to provide userinterface features 121 that are based on the selected service option.The user can then make a request for the on-demand service based on theselection. In one example, when the user makes a request, a confirmationuser interface feature 121 can be provided by the on-demand serviceapplication 110. From this user interface feature, the user can view thedetails of the request, such as what account or credit card to charge(and can edit or choose a different payment method), provide specificrequests to the driver, enter a promotional code for a discount,calculate the price, cancel the request, or confirm the request. As analternative, the request can be automatically confirmed withoutdisplaying a confirmation user interface feature 121.

After the user confirms the request for the on-demand service, theon-demand service application 110 can provide the service request 117 tothe on-demand service system 170 via the service interface 125. In someexamples, the service request 117 can include the service locationspecified by the user (e.g., the location where the user would like theservice to be performed or provided), the user's account information,the selected service option, any specific notes or requests to theservice provider, and/or other information provided by the user. Basedon the received service request 117, the on-demand service system 170can arrange the service between the user and an available serviceprovider that is qualified and capable of providing the on-demandservice. The on-demand service system 170 can provide additionalprovider information 173 to the on-demand service application 110, suchas the particular service provider who will be fulfilling the service,the service provider's ratings, etc., so that this information can beprovided to the user on a user interface 121.

Methodology

FIG. 2 illustrates an example method for providing on-demand serviceuser interface features on a computing device, according to anembodiment. A method such as described by an embodiment of FIG. 2 can beimplemented using, for example, components described with an embodimentof FIG. 1. Accordingly, references made to elements of FIG. 1 are forpurposes of illustrating a suitable element or component for performinga step or sub-step being described.

The on-demand service application can automatically determine thecurrent location of the computing device (step 210). According todifferent implementations, the current location of the computing device(or the selected service location for the on-demand service) can bedetermined based on location data provided by a geo-aware resource, suchas a GPS component of the computing device (sub-step 212), based on userinput to search and/or select particular locations (sub-step 214),and/or based on historical data of previous pickup locations of the user(sub-step 216). Using the current location or the service location ofthe user, a region or area (that includes the current location or theservice location) in which the on-demand services are to be performedcan be determined by the on-demand service application and/or theon-demand service system. In this manner, the on-demand service systemcan identify available service providers (e.g., drivers, food trucks,dessert providers, mariachi bands) in the region that can perform theon-demand service.

Based on the determined region and/or the determined current location orservice location, a multistate selection feature for selecting one ormore of a plurality of service options can be presented on a display ofthe computing device (step 220). The multistate selection feature canidentify, and enable a user to select one of various service optionsavailable for a particular on-demand service. For example, themultistate selection feature can identify the specific available vehicletypes (e.g., Sedan, Taxi, SUV, hybrid vehicle, electric vehicle,limousine, etc.) that the user can request for an on-demand transportservice. The multistate selection feature identifies only those vehicletypes that are available in that region to provide the on-demandtransport service, so that vehicle types that are unavailable cannot beselected by the user. For example, in one region, such as a particularcity, only Sedans and Taxis may be available, whereas in another city,Sedans, Taxis, and SUVs may be available for transport.

The user is enabled to interact with the multistate selection feature inorder to make a selection of one or more of the plurality of serviceoptions (step 230). In one example, the multistate selection featurethat is displayed to the user can be a slider panel with a selectableicon that can slide along a track. In other variations, the multistateselection feature can include features to toggle on or off each of thedifferent available service options in that region. For example, on amobile computing device with a touch-sensitive display, the user can tapon the different service options to cause the selectable icon to move tothe selected option, or hold and drag the selectable icon between thedifferent service options along a track or path. In some instances, whenthe user moves the selectable icon between the different serviceoptions, an indication can be displayed to provide feedback to the user(e.g., when the SUV vehicle type is selected for a transportapplication, the selectable icon can display an image of an SUV ratherthan an image of a Sedan or other previously selected vehicle type).

Once the user makes a selection of a service option, the applicationdisplays user interface features that are region-specific andselection-specific. In one implementation, a region-specific summaryuser interface is presented based on the selected service option of theuser (step 240). The summary user interface can be region-specificbecause different regions can have different pricing structures based onusage of the service in the city, the amount of available serviceproviders and/or users, the overall cost of living, etc. The summaryuser interface can provide a variety of region-specific andselection-specific content to the user so that the user can specify thetransport service he or she prefers.

Again, referring to the on-demand transport service example, the summaryuser interface can identify the estimated time of arrival of the driver(having the selected vehicle type) to the user's current location orservice location (e.g., pickup location). The summary user interface canalso display the region-specific average fare for the vehicle of theselected type (e.g., the average fare can be an estimated fare based onthe locations of the available vehicles and the location of the user),and identify the maximum capacity (number of people the vehicle candrive at once) for the selected vehicle type.

In some implementations, the summary user interface can also bedisplayed concurrently with the multistate selection feature so thatwhen the user changes the selected service option to select a differentservice option, the summary user interface can dynamically alter thecontent based on the adjusted selections. In this manner, the user caneasily view the differences (e.g., differences in cost, vehicle size,estimated time for performing the service, estimated time of arrival,types of foods available, etc.) between the service options to make abetter judgment on what on-demand service options to request.

User Interface Examples

FIGS. 3A-3H illustrate examples of user interfaces that are displayed toa user to enable the user to request an on-demand service, according toan embodiment. FIG. 3A illustrates a multistate selection feature asdescribed in FIGS. 1-2 and FIG. 3B illustrates a summary panel(concurrently with the multistate selection feature) as described inFIGS. 1-2. FIGS. 3C-3H illustrate a set of user interfaces thatillustrate examples of user interfaces described in FIGS. 1-2. Forexample, the home page user interfaces 300 a, 300 b, 380 of FIGS. 3C,3E, 3G, respectively, and the summary user interfaces 350 a, 350 b ofFIGS. 3D, 3F, respectively, illustrate user interfaces that can beprovided by a transport service application (e.g., which is an exampleof an on-demand service application) running or being operated on auser's computing device (e.g., a smart phone).

When a user initiates and operates the on-demand service application onhis or her computing device, for example, a home page user interface canbe provided to the user. The user can interact with features on the homepage user interface in order to request a service. In someimplementations, the home page user interface can include a multistateselection feature 320, as illustrated in FIG. 3A. The multistateselection feature 320 can include a track 321 and a slider feature 322that can be manipulated by the user (via an input mechanism) to be movedalong the track 321. Each resting point or “stop” on the track cancorrespond to a particular service feature or option that the user canselect when requesting an on-demand service. The available serviceoptions can be identified with an identifier 325.

In some cases, based on the user's region, different service options canbe provided with the multistate selection feature 320. For example, ifthe on-demand service application corresponds to a food deliveryservice, the service options provided with the multistate selectionfeature 320 can correspond to types of foods that are available in theuser's region. The multistate selection feature 320 can be presented onthe display to include only service options that are available so thatoptions that are unavailable in that locale are not displayed or aredisplayed in a different fashion to be distinguishable to the user(e.g., a different color, shading, text type, etc.). In another example,the multistate selection feature 320 can prevent the user from making aselection of a service option that is unavailable if the user attemptsto select a stop that corresponds to an unavailable service option. Oncethe user makes a selection, a summary panel can be provided to the userto display additional detail about the user's selection.

FIG. 3B illustrates a summary panel that can be displayed to the user bythe on-demand service application. Depending on implementation, thesummary panel 360 can be provided independently of the multistateselection feature 320 or be provided concurrently with the multistateselection feature 320. The summary panel 360 can provide region-specificinformation that also corresponds to the service option selection madeby the user on the multistate selection feature 320. The summary panel360 can include a plurality of sections 361, 363, 365 that each includedynamically provided content that is region-specific andselection-specific.

For example, for an on-demand entertainment application, the user canselect a mariachi band via the multistate selection feature 320 (e.g.,instead of a string quartet or jingle singing group, etc., that isavailable in the region). The summary panel 360 can include specificinformation about available mariachi bands in the user's region. Thesummary panel 360 can provide the average, actual, or estimated cost forthe mariachi band in section 361, the number of band members availablein section 363, or the earliest the band can perform the service insection 375, or other information, etc., to quickly provide the userwith sufficient details in placing the order. In this manner,functionality, such as communicating a variety of information to theuser, can be aggregated and provided to the user in an efficient anduser-friendly manner.

FIGS. 3C-3H illustrate user interfaces that illustrate examples of userinterfaces that are displayed by an on-demand service application. Inparticular, the user interfaces can be provided by an on-demandtransport application. In various examples, features described in FIGS.3C-3H can also be provided by other on-demand service applications(e.g., applications that can enable the user to request other on-demandservices).

In FIG. 3C, a home page user interface or request user interface 300 acan be presented on the display of the user's computing device. The homepage user interface 300 a can include a service location identifier 310that identifies the determined current location of the computing deviceor the service location that the user has specified via user selections.In some examples, the service location identifier 310 can firstautomatically display the determined current location of the computingdevice without user selection. The service location identifier 310 canalso be selectable by the user to change the current location (e.g., ifthe current location is incorrect) or the service location (e.g., theuser will be somewhere else in the next few minutes and would prefer toget the service at a different location than the current location). Theservice location identifier 310 can display an address, a name of alocation (e.g., store, park, restaurant, venue), street intersections,or user programmed identifier (e.g., “work,” “parent's house,” or “home”of the user).

The home page user interface 300 a can also include a multistateselection feature 320. The multistate selection feature 320 can includea slider feature 322 that can be manipulated by the user to be movedalong a track 321. The multistate selection feature 320 can identify aplurality of service types that are available for providing, forinstance, a transport service for the user based on the user's currentlocation (or pickup location). Depending on the user's location,available service providers can be determined for a particular regionthat includes the user's current location or pickup location. Forexample, the region can be a city, such as San Francisco, Calif., andthe multistate selection feature 320 can identify vehicle types that areavailable for providing the transport service within the generalvicinity or area of San Francisco, Calif.

In the example provided, the multistate selection feature 320 isregion-specific so that only the vehicles that are specificallyavailable in San Francisco, Calif. can be selected by the user. Theavailable vehicle types in FIG. 3C include Taxis, Sedans, and SUVs orAny type of vehicle available to the user. These vehicle types can eachbe indicated by an identifier 325 that is shown above a correspondingselection point along the track 321. The vehicle types that are notavailable in the region can be identified differently so that the usercan determine which vehicle types cannot be selected for the transportservice. In FIG. 3C, for example, “UBERx” vehicles, which are identifiedto be a different type of vehicle as compared to Taxis, Sedans, or SUVs(such as a limousine or hybrid vehicle), are not available in the regionof San Francisco, Calif. Some examples to differentiate available typesof vehicles as compared to unavailable types of vehicles include usingproviding an identifier 327 with different characteristics (e.g.,varying font colors, font shading, font sizes), or by not including anidentifier in its entirety or blocking out the identifier 327 fromappearing on the multistate selection feature 320.

In some variations, when the user manipulates the slider feature 322 bymoving it between the different selection points along the track 321,the identifier 325 of the selected vehicle type can also be changed toidentify the selection. For example, the identifier “Sedan” is elevatedas compared to the other identifiers to indicate the selection of“Sedan” type vehicles. In other examples, the selected identifier can bealtered in size, color, font, etc., to easily indicate to the user ofthe selection. As an addition, the graphic 323 provided within theslider feature 322 can dynamically change in order to correspond to theselection (e.g., a graphic of a vehicle that corresponds to a selectedvehicle type, a graphic of food type, a graphic of an entertainmentselection, etc.).

In one implementation, the slider feature 322 can initially bepositioned at a default vehicle type or a default vehicle type that isselected and programmed by the user. In other variations, the sliderfeature 322 can be initially positioned at a vehicle type that has mostfrequently been used by the user to request the transport service, orcan initially be positioned at a vehicle type that was previously usedby the user to request a transport service.

The home page user interface 300 a can also include a map thatillustrates at least a portion of the region in which the user's currentlocation or pickup location is located in. The map can include a graphicpin 313 that indicates the user's current location or pickup location.In some implementations, the home page user interface 300 a can alsoinclude a feature (proximate to or as part of the graphic pin 313) thatindicates an estimated time of arrival 330 of an available serviceprovider having a vehicle of the selected type, and a request selectionfeature 340 to enable the user to request the transport service usingthe selected vehicle type. The estimated time of arrival 330 candynamically be altered in response to the user changing the selection bymoving the slider feature 322 along the path 321.

In some examples, the on-demand service application that operates on theuser's computing device can communicate with the on-demand servicesystem to receive real-time information about service providers in thedetermined region of the user. The on-demand service system cancontinually (periodically) receive data from the computing devices ofthe service providers (e.g., such as GPS data, driver and vehicleinformation) in order to determine the current location of the serviceproviders, the speed and direction in which the service provider ismoving, whether a service provider is currently providing a transportservice (e.g., is currently occupied), etc., and other service providerinformation. The on-demand service application can receive informationabout one or more service providers in the vicinity of the user'scurrent location or pickup location in order to provide real-timeinformation to the user.

For example, based on the selected vehicle type and determined region,one or more graphic vehicle indicators 315 (if any) can be dynamicallyprovided on the map to indicate to the user the current/real-timelocations and movements of the service providers having the selectedvehicle type. The graphic vehicle indicators 315 can indicate to theuser that the driver is currently available to service the user and iswithin the region or portion of the region in which the user's currentlocation or pickup location is located in. In the example illustrated inFIG. 3C, the user has selected Sedan vehicles as the vehicle type inwhich he or she would like to potentially request a transport service.The map can display graphic vehicle indicators 315 that visuallyrepresent Sedan vehicles that are near the current location or pickuplocation of the user. If the user changes the vehicle selection usingthe multistate selection feature 320 to select SUVs, the graphic vehicleindicators 315 of the Sedans can be removed from the map and one or moregraphic vehicle indicators 315 (if any) of SUVs can be provided on themap.

In one implementation, one or more graphic vehicle indicators 315 canmove on the map corresponding to the real-time and real-life movementsof the service providers' vehicles relative to the user's currentlocation or pickup location. The movements of the graphic vehicleindicators 315 can be determined using provider data (e.g., via providerinformation 177 transmitted by the transport service system in FIG. 1)that includes GPS data of the drivers' vehicles.

In one example, the transport service system can also use one or moredatabases of streets and roads for maps (e.g., including externaldatabases maintained by third parties or other map sources) to determinehow the graphic vehicle indicators 315 can be oriented and moved on amap that is presented to the user (e.g., as part of the home page userinterface 300 a). The one or more databases can include geocodinginformation that make up individual streets and roads. By taking the GPSpoints or coordinates of available vehicles (from the service providers'devices) and drawing lines between the points, the GPS points and linescan be aligned with the geocoding information from the databases. Inthis manner, real-time vehicle movements and locations can be correlatedto maps of streets and roads so that the graphic vehicle indicators 315can be displayed to the user. In addition, by map-fitting the GPS pointswith the known geolocations of streets, the transport service system cancorrect for inconsistencies and smooth out lines between GPS points sothat the corresponding graphic vehicle indicators 315 can be accuratelydisplayed on a map to the user on the user's computing device (e.g., onuser interface 300 a).

The graphic vehicle indicators 315 can then be oriented and aligned inthe appropriate directions on the appropriate streets so that the usercan easily determine the locations and directions of movement of nearbyservice provider vehicles, and determine what side of the street theservice provider vehicles are on.

In some implementations, when the user makes a selection of a vehicletype using the multistate selection feature 320, a summary userinterface 350 a can be presented to the user. As illustrated in FIG. 3D,the summary user interface 350 a can overlay the previously displayeduser interface feature, such as the home page user interface 300 a, sothat a portion of the previously displayed user interface feature can becontinued to be displayed to the user. For example, the summary userinterface 350 a can include a summary panel 360 that is displayed overthe previously displayed user interface feature, such as the home pageuser interface 300 a. In some examples, the summary panel 360 can bepresented concurrently with the multistate selection feature 320. Inother variations, a semi-transparent shading 370 can overlay a portionof the previously displayed user interface feature so that the user cancontinue to view information provided on portions of the previouslydisplayed user interface.

The summary panel 360 can include a variety of information related to atransport service that is specific to the locality (e.g., the region) ofthe user and the selected vehicle type. The summary panel 360 caninclude an estimated time of arrival (ETA) section 361, an average faresection 363, and a maximum capacity section 365, that each includedynamically provided content that is location-specific (e.g.,region-specific) and vehicle-specific. Each of the sections can alsoinclude a graphic to represent the corresponding content (e.g., a watchor clock, a receipt or ticket, person). Because the available serviceproviders continue to drive around the region, pick up other customers,make traffic stops, etc., the information provided within the sections361, 363, 365 can also be dynamically adjusted based on the real-timeconditions of the service providers (e.g., the estimated time of arrivalcan be decreased or increased, or the average estimated fare can beadjusted).

In addition, the location-specific information is based on the selectedvehicle type, when the user changes the selection of a vehicle type, theinformation provided within the sections 361, 363, 365 can bedynamically adjusted. For example, when the summary panel 360 ispresented concurrently with the multistate selection feature 320 on thesummary user interface 350 a, the user can also move the slider feature322 to select different vehicle types and cause the content within thesections 361, 363, 365 to change accordingly. The maximum capacity of anSUV or Van can be more than four, for example, compared to a Sedan,which can be three, and the closest SUV or Van can be much further awaythan a Sedan, which can cause the estimated time of arrival to bealtered. In another example, a Sedan can be cheaper than an SUV in theuser's current region, so that the average estimated fare can bedynamically decreased in cost.

The user can also select a completion feature 367 when he or she hasfinished viewing the information corresponding to the selected vehicletype. Selecting the completion feature 367 can close the summary userinterface 350 a to remove the summary panel 360. In other examples,selecting other portions of the summary user interface 350 a (e.g.,selecting on a region of the semi-transparent shading 370) can cause thesummary user interface 350 a to be closed (e.g., no longer presented tothe user). When the user is done selecting the vehicle type, other userinterface features can be provided to enable the user to request thetransport service.

The transport application can also provide transport specificinformation to the user using languages, symbols, and/or prices based onthe user's location. For example, the different vehicle types displayedin the multistate selection feature 320 can be identified in French,German, Spanish, etc., based on the country the user operates thetransportation application in (e.g., instead of “Sedan” or “Any”). Auser can choose to have information provided by the transportapplication in a particular language (e.g., select a language for theapplication), such as when first installing the transport application orby selecting a language when first registering the user's device, etc.The user is also free to change languages upon his or her preference.

In another example, the content within the sections 361, 363, 365 of thesummary user interface 350 a can also be provided in a language selectedby the user and/or based on the user's location. If the user wascurrently in London, England, for example, the average fare section 363would display the average cost for the selected vehicle type in pounds(GBP) instead of dollars (USD). This enables the transport applicationto provide text information in a language selected by the user, while atthe same time, tailor the content based on the user's location. Forexample, the user can prefer to operate the transport application inFrench, while living in London, England. The text information can beprovided by the transport application in French, yet continue to providecontent based on standards used in England (e.g., provide average fareinformation in pounds).

FIG. 3E illustrates another example of a home page user interface orrequest user interface 300 b. A user can interact with the home pageuser interface 300 b, such as the request selection feature 340, inorder to request a service (e.g., a transport service). The home pageuser interface 300 b can have a similar layout as the layout of the homepage user interface 300 a illustrated in FIG. 3C, but have somedifferences. For example, in the home page user interface 300 b, onlyfour types of available service options are displayed on a multistateselection feature 320.

FIG. 3F illustrates another example of a summary user interface 350 b.The summary user interface 350 b can have a similar layout at the layoutof the summary user interface 350 a illustrated in FIG. 3D. In oneexample, the summary panel 360 can display information related to atransport service that is specific to the locality (e.g., the region) ofthe user and the selected vehicle type (e.g., “Black Car”). In additionto an estimated time of arrival (ETA) section 361, an average faresection 363, and a maximum capacity section 365, the summary panel 360can also include a selectable fare feature 369 that can displayadditional or detailed information about the fare.

As an addition or alternative, the home page user interface 380 of FIG.3G can also be provided by the transport application. The home page userinterface 380 can correspond to a transition interface that is displayedwhile content in the request selection feature 340 is being updated ormodified. For example, while the transport application is initiallyloading or is processing information as a result of user input (e.g.,manipulation of slider feature 322), different graphics/text can beprovided within the request selection feature 340 and/or the estimatedtime of arrival 330.

The home page user interface 380 (and other user interfaces for otheron-demand services as described in FIGS. 1-3F) can also include a priceadjustment (or surge pricing) selectable feature 381. In someimplementations, the transport service system can dynamically adjust theprice for transport service in a given region based on real-timeconditions. Based on real-time conditions, such as the high (or low)demand of transport service requests or the high (or low) supply ofavailable transport service providers, the transport service system canincrease or decrease the price for the transport service in that region.When the transport service system determines that prices are to bealtered, the price adjustment feature 381 can be provided to a userinterface feature, such as the home page user interfaces 300 a, 300 b,380.

When user selects the price adjustment feature 381, informationalcontent about the adjusted pricing can be presented to the user. Forexample, the user can be notified of the price adjustment, how much theprice is being adjusted, why the price is being adjusted, etc., toprovide the user with full disclosure before the user agrees to requestthe service at that price. In some variations, a price adjustment icon383 can be provided with one or more vehicle types in a user's region toinform the user which particular vehicles are subject to the priceadjustment. Dynamic price adjustment is described in U.S. ProvisionalPatent Application No. 61/612,471, filed Mar. 19, 2012 (theaforementioned application being incorporated by reference in itsentirety).

The home page user interface 380 can also include a promotionalselection feature 391. The promotional selection feature 391 can beselected by a user to view dynamically provided promotional content thatthe user can view and request when requesting the transport service.Promotional content is further described with FIGS. 8A-8D below.

FIG. 3H illustrates another example of a user interface feature that canbe displayed by an on-demand service application. In some examples, theuser interface 395 can be displayed by the on-demand service applicationin response to a user interacting with a previously displayed userinterface (e.g., such as the user interfaces 300 a, 300 b, 350 a, 350 b,380, 500 of FIG. 5A, etc.) The user interface 395 displays a full screen(or close to full screen) view of an expanded map 396 that providesinformation about the user's location (marked by a graphic pin, such asthe graphic pin 313 of FIG. 3C) as well as one or more graphic vehicleindicators that are dynamically provided on the map 396 to indicate thecurrent/real-time locations and movements of the available serviceproviders.

The user interface 395 can be presented with an expanded map 396 thathas been expanded to fit the size of a display screen of the computingdevice in response to a user selection. The user selection cancorrespond to, for example, the user interacting with (e.g., tapping,tapping and holding, or double tapping, etc.) a portion of a map of apreviously displayed user interface. For example, if the user interface380 of FIG. 3G is presented to the user and the user provides an inputto cause the map to be expanded, the map can expand from a first size(e.g., from the window size in FIG. 3G) to a second size (e.g., to thesize in FIG. 3H). In this manner, the user can see a full view of thegeneral region, such as where the user is, the nearby service providers,etc., before committing to request the service. In some variations, agraphical transition can be provided to show the transition between themap in a previously displayed user interface to the expanded map 396 inthe user interface 395.

The user interface 395 can also include a reduce feature 397 that can beselectable in order to return the map to a previous size and re-displaythe previously displayed user interface feature. In some cases, thegraphic transition can show the transition of the expanded map 396reducing in size from the larger size to a smaller size, such as the mapin FIG. 3G. The user can then again view the different options, such asthe multistate selection feature 320 of FIG. 3G. In another example, theuser interface 395 can be displayed in response to the user interactingwith the map of the confirmation user interface 500 of FIG. 5A.Selecting the reduce feature 397 would then cause the confirmation userinterface 500 to be re-displayed so that the user can view theinformation before confirming the request.

FIGS. 4A-4C illustrate examples of user interfaces that are displayed toa user to enable the user to select a service location for an on-demandservice, under another embodiment. In some variations, the locationsuggestion user interface 400, and/or the location search userinterfaces 450, 495 illustrate user interfaces that can be provided bythe on-demand service application in response to the user requesting tomake a manual selection of a service location.

The location suggestion user interface 400 enables a user to selectparticular locations, such as stores, restaurants, parks, venues, etc.,that can be precisely and easily identified by a service provider whenthe user requests to have the on-demand service be performed orfulfilled. For example, the user can select the location at which theuser would like his or her food to be delivered at (e.g., the user'soffice or home, or a friend's apartment, etc.) or the location where themariachi band should play at (e.g., at a bar or restaurant). In anotherexample, referring back to FIG. 3E, when accessing a transport serviceapplication, the user can select the pickup location identifier 310 inorder to view suggestions 430 of various locations and venues that arelocated in the vicinity of the user's current location. If the user isat Nanigans SF, for example, and would like to be picked up there, theuser can select the entry 440 for Nanigans SF as the pickup location forthe transport service. Once the user makes the selection, the pickuplocation identifier 310 of FIG. 3E can identify the pickup location tobe Nanigans SF.

In some implementations, other suggested entries 440 can be providedbased on historical/previous pickup locations of the user and/or basedon user-specific data. Based on the current location of the computingdevice, the on-demand service application can access user informationthat includes previously requested services and/or personal userinformation (e.g., the user's home address, the user's place ofbusiness, the user's preferences) to provide one or more user-basedlocation entries 420, 440. Historical information, such as the frequencyor recency of previous service locations that the user requested serviceto be performed at, can be used to provide recent and/or recommendedpoints of interest to the user.

In this manner, the on-demand service application can predict whatparticular service locations the user would like to select. The one ormore suggested entries 440 can be displayed based on a combination ofthe user's current location (e.g., the nearness of service locations)and the recency of previous service locations and/or the total frequencyof particular service locations. In some examples, the suggestedlocations can also be ranked based on the scores of the suggestedlocations determined using a recency, frequency, or nearness algorithm.The user can also select the search field 410 in order to search forother locations or venues that are not listed in the suggestions 420,430. A cancellation feature 415 can be selected by the user to close thelocation suggestion user interface 400 and request service at thelocation already determined and identified on a location identifier(such as the pickup location identifier 310 of FIGS. 3C, 3E).

The location search user interface 450 of FIG. 4B enables the user tomanually provide input (e.g., such as at least portions of an address, aname of a store, a street name, a city, etc.) in the search field 460 tosearch for particular locations, stores, buildings, or venues to selectas a service location. In one implementation, the on-demand serviceapplication can communicate, via APIs, with one or more otherapplications or programs to display a keyboard 490 as part of thelocation search user interface 450. As the user inputs characters in thesearch field 460, entries 480 can be provided that match (at least inportion) the characters provided in the search field 460. The user canalso select the “search” feature 470 to cause the on-demand serviceapplication to perform a search (e.g., of one or more internal andexternal location or map databases of the on-demand service system)using the search term or characters provided in the search field 460 asthe search query. The search results 496 can be provided on the locationsearch user interface 495 of FIG. 4C for user selection. In somevariations, the location search user interface 495 can also display afeature 497 that identifies one or more sources that were queried todetermine the search results 496.

FIG. 5 illustrates an example method for determining a location relatedto an on-demand service request, under an embodiment. A method such asdescribed by an embodiment of FIG. 5 can be implemented using, forexample, components described with an embodiment of FIG. 1. Accordingly,references made to elements of FIG. 1 are for purposes of illustrating asuitable element or component for performing a step or sub-step beingdescribed. Depending on implementation, one or more of the stepsdescribed in FIG. 5 can be performed by the on-demand serviceapplication 110 and/or the one-demand service system 170.

The user can provide a service request input via a mobile computingdevice (step 510). In some embodiments, the user can provide servicerequest input without manually specifying a location. For example, theuser may specify a pickup or drop-off region to coincide with thelocation where the user requested service on their geo-aware device. Inthe example of requesting a transport service, a user can operate anon-demand service application and request the transport service usingone or more user interface features (such as described with FIGS. 1-4C).In response to receiving the selection, the service application canutilize, for example, the mapping/GPS functionality of the computingdevice to determine a region of the device when the request is made.

Accordingly, in one example, the transport request can include a pickupregion (sub-step 512) and/or a drop-off region (sub-step 514). Referenceto “region” is intended to mean an area that encompasses multiplelocations, where each location identifies or correlates to an address ora landmark. As the pickup region or drop-off region is not accurate to aspecific location, the on-demand service application and/or theon-demand service system can attempt to identify a more precise locationrelated to the service request.

The user's mobile computing device can determine its general position orregion using a GPS component. However, in some cases, the GPSmeasurements of the position of the device can identify a region (e.g.,a half-block or block, a shopping center, a business district, or alarge building, etc.) encompassing many locations (e.g., multiplebusinesses or addresses), rather than a specific location (e.g., asidentified by specific address). In other examples, the user may specifya region as input by, for example, selecting an area of a map as apickup region or a drop-off region. Again, such a specified region canpoint to a neighborhood having multiple homes at the end of a street,can point to a shopping center with numerous entrances and stores, orcan point to a strip mall having many stores within a small geographicarea, etc.

The on-demand service application and/or the on-demand service systemcan use location information about the pickup region and/or the drop-offregion to determine one or more locations of interest within the region(step 520). In one implementation, the location information can becross-referenced with the other sources or databases, such as a businessdirectory, that maintain location information with business, stores,restaurants, venues, landmarks, etc. (sub-step 522). Bycross-referencing the location information with a business directory,for example, the on-demand service application and/or the on-demandservice system can identify one or more locations of interests withinthe region specified with the service request (e.g., a region specifiedby the user and/or a region of the device when the request was made).

The pickup region and/or the drop-off region can also be compared withhistorical locations related to the user (step 530). In many situations,a user of a service application can request a service at a location inwhich the user previously requested the service. Based on the user'shistorical use data, the on-demand service application and/or theon-demand service system can compare the region specified with theservice request in order to determine if the user is likely requestingservice at a location related to the user. In some examples, thelocations related to the user can include the user's most recentlocation(s) (e.g., previous service locations requested within a certainpast time frame) (sub-step 532), the user's most common locations(sub-step 534), and the user's previously visited location that isclosest to the user's current location and/or the user's specifiedregion (sub-step 536).

Based on the determined locations of interest and based on thecomparison, the on-demand service application and/or the on-demandservice system can determine one or more likely locations for the user(step 540). In some variations, the on-demand service application canprovide a prompt as part of a user interface feature asking the userwhether the likely location is a location the user would like to bepicked up at or dropped off at (e.g., “Do you want to be picked up atJoe's Coffee Shop?”). If the user confirms the location, the servicerequest can be processed and the service can be arranged for the user(step 550). In one example, if the user provides input to specify thatthe recommended likely location is incorrect, the on-demand serviceapplication can determine the next likely location and provide a secondprompt to the user (e.g., and so forth). In this manner, the serviceapplication and/or the on-demand service system can attempt to provide amore precise location for the user based on the location informationprovided with the user's service request.

As an addition or an alternative, the on-demand service application candetermine one or more likely locations for a user without user input asto user's location or region. For example, for a transport servicerequest, the on-demand service application can automatically determinethe user's pickup region using geo-aware resources (e.g., a GPScomponent) of the user's computing device and assume that the determinedregion includes a location that the user wishes pickup at. Accordingly,when the user requests transport (e.g., without specifying a particularlocation), the on-demand service application can prompt the user with adetermined likely location that is based on the user's location at thetime of the request.

FIGS. 6A-6B illustrate examples of confirmation user interfaces that aredisplayed to a user when an on-demand service has been requested,according to an embodiment. For example, the confirmation user interface600 of FIG. 6A can illustrate a user interface that is provided by atransport service application in response to the user requesting atransport service. After the user selects a vehicle type, the user canrequest the transport service by selecting the request selection feature340 of FIGS. 3C, 3E. Similarly, a confirmation user interface can beprovided in response to the user requesting other on-demand servicesusing other respective on-demand service applications.

A confirmation user interface 600 can provide a variety of informationthat the user can confirm before the on-demand service system arrangesthe on-demand service for the user. Referring back to the transportservice example, the confirmation user interface 600 can include apickup location marker 620 and a pickup location panel 610 thatidentifies the selected vehicle type (e.g., Sedan) as a graphic and/ortext, and the pickup location (e.g., automatically determined from thecurrent user location or determined from user selections). Theconfirmation user interface 600 can also include additional features,such as markers 630 (a marker identifying the destination, if selectedby a user via a user interface, or a marker identifying the currentlocation of the driver that is to provide the transport service). Asanother example, if the user is requesting an ice cream truck, theconfirmation user interface 600 can include a service destinationmarker, a current ice cream truck location marker, and other additionalinformation.

The confirmation user interface 600 can also provide the user'sfinancial account information 640 (e.g., a bank routing and/or accountnumber, a credit card number, etc.) that is used to pay for therequested on-demand service. The user can have the option to use adifferent account to pay for the service if he or she prefers. In somevariations, the confirmation user interface 600 can also provideselectable features 650, 660, 670 for calculating the price or fare,providing a specific note or additional information to the driver, andfor entering a promotional code to receive discounts or otherpromotional services.

Once the user views the information provided, the user can select theconfirmation feature 680 to confirm the requested on-demand service. Theon-demand service system can then receive appropriate information fromthe on-demand service application, charge the account, communicate withavailable service providers in the vicinity of the user's servicelocation, arrange the on-demand service between the user and a driver,and/or provide a transaction confirmation or receipt to the user. If theinformation provided on the confirmation user interface 600 isincorrect, or the user wishes to cancel the request for whatever reason,the user can simply select the “cancel” feature to change the serviceoptions and/or the service location.

FIG. 6B illustrates another example of a confirmation user interface690. The confirmation user interface 690 can present similar informationto that of the confirmation user interface 600 of FIG. 6A, but arrangedin a different manner. For example, instead of displaying a pickuplocation panel 610 (e.g., as displayed in FIG. 6A), the confirmationuser interface 690 can simply provide a pin representing the user'slocation and/or the pick up or drop off location on the map itself.

The confirmation user interface 690 can also enable a user to correct orafter a pick up location or drop off location without having tobacktrack or return to previously displayed user interfaces (e.g., userinterfaces for requesting a service or for searching for a location).The user can, for example, interact with the service location identifierand/or the displayed map in order to change a service location. A usercan also interact directly with the displayed map of the confirmationuser interface 690 in order to dynamically adjust the displayed portionof the map (e.g., pan, zoom in, zoom out). The user can zoom in/outand/or pan the map in one or more directions, for example, to see theclosest available service provider(s) or the overall geography (streets,freeways, locations of interest, etc.) of the region. In this manner,the confirmation user interface 690 can dynamically display differentportions of the map based on user preference.

In some implementations, the confirmation user interface 690 can includea confirmation feature 695 that dynamically alters its text (e.g., itscontent within the selectable feature) based on the user selections forthe service. For example, instead of the text “confirm” within theconfirmation feature 680, the confirmation feature 695 can specify“request black car” or “request sedan,” etc., based on the user selectedrequest. Despite the different variations or layouts, the confirmationuser interfaces 600, 690 can display information about the user'srequested service in a clear and informative manner on a single panel.

FIGS. 7A-7B illustrate examples of fare information panels that provideadditional information about a fare for an on-demand service, under anembodiment. In FIG. 7A, a fare information panel 700 can be generatedand displayed as part of a user interface to provide more detailed fareinformation to a user (e.g., for a transport service). The fareinformation panel 700 can be a pop up, for example, in response to auser input for viewing additional fare information. The fare informationpanel 700 can include information about the base fare 710, the cost orfare per minute 720 in situations when the average speed is between 0miles per hour (e.g., the vehicle is stopped) and 11 mph, and the costor fare per mile 730 in situations when the average speed is higher than11 mph. Such information can be provided with a visual chart or graph toenable the user to easily understand the fare amounts for the service.

The detailed information provided in the fare information panel 700 canidentify an estimated or anticipated fare for the service, or canidentify the actual fare that a service provider abides by. The detailedinformation can be adjusted depending the user's location (e.g., theuser's current location, the pickup location and/or destinationlocation, etc.) and the user's selected service option. For example, fora transport service or a delivery service, the determined fares 710,720, 730 can be adjusted depending on the type of vehicle the user hasselected (e.g., via the multistate selection panel). In other examples,the threshold levels for the fares can be adjusted depending on theuser's location or the service option (e.g., instead of 11 mph,increased to 13 mph).

FIG. 7B illustrates an example of the fare information panel 700 asprovided with a user interface of an on-demand service application.Although the fare information panel 700 is displayed with a summarypanel and a multistate selection feature in the example of FIG. 7B, thefare information panel 700 can be provided on other user interfaces,such as with the confirmation user interfaces of FIGS. 6A-6B. The userinterface feature 750 illustrates the fare information panel 700 beingdisplayed as a result of the user selecting the selectable fare feature760 (e.g., “rates”). In other examples, the user can select otherfeatures, such as the average fare section 770 of the summary panel orthe “calculate fare” or “fare estimate” features of the confirmationuser interfaces, in order to cause the fare information panel 700 to beprovided (as a pop up, for example) on the user interface 750. In someexamples, the fare information panel 700 can be located and displayedproximate to or near the feature selected by the user. By providing afare information panel 700, the user can see a comprehensive view of thecosts for a service before making the decision to request the serviceusing the on-demand service application.

FIGS. 8A-8D illustrate an example series of user interfaces that aredisplayed to a user to provide additional content, under an embodiment.In some examples, FIGS. 8A-8D can illustrate a graphical transitionbetween user interface features that occur in a short period of time(e.g., milliseconds, a second, etc.). The user interfaces of FIGS. 8A-8Dcorrespond to interfaces that are provided by an on-demand transportapplication, but features described in FIGS. 8A-8D can also be providedby other on-demand service applications (e.g., applications that canenable the user to request other on-demand services).

In FIG. 8A, a user interface feature 800 for requesting an on-demandservice is presented on a display of the user's computing device. Such auser interface feature 800 can include any one of the user interfacefeatures described in FIGS. 1-7B. In one example, the user interfacefeature 800 can include a promotional selection feature 810. Theon-demand service system can dynamically provide promotions or specials,for example, to the user that the user can request or order whenrequesting the on-demand service. When the user selects the promotionalselection feature 810, promotional content can be presented to the user.The user can then order or request the promotional service, for example,as part of the on-demand service request (e.g., the user gets a discounton the current price or future request, a free dessert, a coupon, etc.).

FIGS. 8B-8D illustrate the user interface feature 800 after the user hasselected the promotional selection feature 810. The user interfacefeatures 800 in FIGS. 8B-8D depict a graphical transition to transitionbetween the initially displayed user interface feature 820 and adifferent user interface feature 830. In one example, the graphictransition can represent a page flip or a page fold. In other examples,the graphical transition can include wrinkling, (like the wrinkling ofan accordion), sliding away of the initially displayed user interfacefeature 820 and/or sliding in of the new user interface feature 830,pulling up or pulling down of a user interface feature (like the pullingof a curtain or window blinds, or sliding of a pocket door), or othergraphical transitions or combinations of graphical transitions.

Once the subsequent user interface feature 830, such as a promotionaluser interface, is provided, the user can view the information displayedand navigate back to the previous (or different) user interface (e.g.,back to a home page user interface or confirmation user interface,etc.).

As an addition or alternative, the graphical transitions described withrespect to FIGS. 8A-8D can be used to transition between any of the userinterface features described in FIGS. 1-7B. For example, referring backto FIG. 3C or 3E, if the user selects the “profile” feature (identifiedby the image of a person) or “information” feature (identified by an “i”inside a circle), a profile menu or an information menu, respectively,can be pulled down to overlay a portion of the displayed user interfacefeature (e.g., the home page user interfaces 300 a, 300 b). Thegraphical transition can provide a seamless transition between thedisplayed user interface feature and the pulled-down profile menu or theinformation menu that overlays, the map, for example, while continuingto display the multistate selection feature 320. In another example,graphical transitions, such as a pulling of or pushing of a userinterface or a user interface feature, can be displayed when the userselects a price adjustment feature 381 of FIG. 3G.

Still further, a graphical transition can include a visual expansion(from a first size to a second larger size, for example) of a feature ona user interface and/or a visual reduction of a feature. Referring toFIGS. 3C and 3H, for example, an input by a user to expand the map thatis displayed with the user interface 300 a of FIG. 3C can cause a visualexpansion of the map from the manner displayed in the user interface 300a to a full size image of the map as displayed in the user interface 395of FIG. 3H. Similarly, a user input selecting the reduce feature 397 ofthe user interface 395 can cause a visual reduction from the full sizeimage of the map 396 to the previous size of the previous user interfacefeature. In some variations, the pull down menus can be semi-transparentto continue to display the overlaid portions of the user interfacefeature in the background.

Hardware Diagrams

FIG. 9 is a block diagram that illustrates a mobile computing deviceupon which embodiments described herein may be implemented. In oneembodiment, a computing device 900 may correspond to a mobile computingdevice, such as a cellular device that is capable of telephony,messaging, and data services. Examples of such devices includesmartphones, handsets or tablet devices for cellular carriers. Computingdevice 900 includes a processor 910, memory resources 920, a displaydevice 930 (e.g., such as a touch-sensitive display device), one or morecommunication sub-systems 940 (including wireless communicationsub-systems), input mechanisms 950 (e.g., an input mechanism can includeor be part of the touch-sensitive display device), and one or morelocation detection mechanisms (e.g., GPS component) 960. In one example,at least one of the communication sub-systems 940 sends and receivescellular data over data channels and voice channels.

The processor 910 is configured with software and/or other logic toperform one or more processes, steps and other functions described withimplementations, such as described by FIGS. 1-8D, and elsewhere in theapplication. Processor 910 is configured, with instructions and datastored in the memory resources 920, to operate an on-demand serviceapplication as described in FIGS. 1-8D. For example, instructions foroperating the service application to display various user interfaces,such as described in FIGS. 3A-8D, can be stored in the memory resources920 of the computing device 900. In one implementation, a user canoperate the on-demand service application so that location data 965 canbe received by the GPS component 960. The location data 965 can be usedby the application to present user interface features that are madespecific to the current location of the computing device 900.

The location data 965 can also be provided to the on-demand servicesystem using the communication sub-systems 940. The communicationsub-systems 940 can enable the computing device 900 to communicate withother servers and computing devices, for example, over a network (e.g.,wirelessly or using a wireline). The location data 965 can becommunicated to the on-demand service system so that when the userrequests the on-demand service, the system can arrange the servicebetween the user and an available service provider. The communicationsub-systems 940 can also receive provider information 945 (such aslocation and/or movement information of drivers in real-time) from theon-demand service system and transmit the provider information 945 tothe processor 910 for displaying driver data on one or more userinterfaces 915.

The processor 910 can cause user interface features to be presented onthe display 930 by executing instructions and/or applications that arestored in the memory resources 920. In some examples, user interfaces915, such as user interfaces described with respect to FIGS. 3A-8D, canbe provided by the processor 910 based on user input and/or selectionsreceived from the user. In some implementations, the user can interactwith the touch-sensitive display 930 to make selections on the differentuser interface features 915 so that region-specific information (that isbased on the user selections) can be provided with the user interfacefeatures 915. While FIG. 9 is illustrated for a mobile computing device,one or more embodiments may be implemented on other types of devices,including full-functional computers, such as laptops and desktops (e.g.,PC).

It is contemplated for embodiments described herein to extend toindividual elements and concepts described herein, independently ofother concepts, ideas or system, as well as for embodiments to includecombinations of elements recited anywhere in this application. Althoughembodiments are described in detail herein with reference to theaccompanying drawings, it is to be understood that the invention is notlimited to those precise embodiments. As such, many modifications andvariations will be apparent to practitioners skilled in this art.Accordingly, it is intended that the scope of the invention be definedby the following claims and their equivalents. Furthermore, it iscontemplated that a particular feature described either individually oras part of an embodiment can be combined with other individuallydescribed features, or parts of other embodiments, even if the otherfeatures and embodiments make no mentioned of the particular feature.Thus, the absence of describing combinations should not preclude theinventor from claiming rights to such combinations.

What is claimed is:
 1. A method for determining a location relating to a transport service on a computing device, the method being performed by one or more processors and comprising: receiving a transport request from a user, the transport request specifying at least one of a pick-up region or a drop-off region; determining one or more locations of interests within the at least one of the pick-up region or the drop-off region; comparing the at least one of the pick-up region or the drop-off region with one or more historical locations related to the user; and determining a likely location based on the determined one or more locations of interest and the one or more historical locations.
 2. The method of claim 1, wherein determining one or more locations of interests includes referencing a business directory.
 3. The method of claim 1, wherein the one or more historical locations related to the user includes one or more locations recently visited by the user.
 4. The method of claim 3, wherein the one or more historical locations related to the user includes one or more locations commonly visited by the user.
 5. The method of claim 4, wherein the one or more historical locations related to the user includes one or more locations previously visited by the user that is closest to the at least one of the pick-up region or the drop-off region.
 6. The method of claim 1, further comprising: in response to determining the likely location, providing a prompt on a user interface feature that asks the user whether the likely location is a location the user would like to be picked up at or dropped off at.
 7. The method of claim 6, further comprising: receiving a user confirmation that the likely location is the location the user would like to be picked up at or dropped off at; and arranging the transport service for the user based on the likely location.
 8. The method of claim 6, further comprising: receiving a user input that specifies that the likely location is not the location the user would like to be picked up at or dropped off at; and determining a second likely location based on the determined one or more locations of interest and the one or more historical locations.
 9. A non-transitory computer readable medium storing instructions that, when executed by one or more processors, causes the one or more processors to perform steps comprising: receiving a transport request for a transport service from a user, the transport request specifying at least one of a pick-up region or a drop-off region; determining one or more locations of interests within the at least one of the pick-up region or the drop-off region; comparing the at least one of the pick-up region or the drop-off region with one or more historical locations related to the user; and determining a likely location based on the determined one or more locations of interest and the one or more historical locations.
 10. The non-transitory computer readable medium of claim 9, wherein the instructions cause the one or more processors to determine one or more locations of interests by referencing a business directory.
 11. The non-transitory computer readable medium of claim 9, wherein the one or more historical locations related to the user includes one or more locations recently visited by the user.
 12. The non-transitory computer readable medium of claim 11, wherein the one or more historical locations related to the user includes one or more locations commonly visited by the user.
 13. The non-transitory computer readable medium of claim 12, wherein the one or more locations previously visited by the user that is closest to the at least one of the pick-up region or the drop-off region.
 14. The non-transitory computer readable medium of claim 9, wherein the instructions cause the one or more processors to: in response to determining the likely location, provide a prompt on a user interface feature that asks the user whether the likely location is a location the user would like to be picked up at or dropped off at.
 15. The non-transitory computer readable medium of claim 14, wherein the instructions cause the one or more processors to: receive a user confirmation that the likely location is the location the user would like to be picked up at or dropped off at; and arrange the transport service for the user based on the likely location.
 16. The non-transitory computer readable medium of claim 14, wherein the instructions cause the one or more processors to: receive a user input that specifies that the likely location is not the location the user would like to be picked up at or dropped off at; and determine a second likely location based on the determined one or more locations of interest and the one or more historical locations.
 17. A mobile computing device comprising: a display; one or more memory resources; and one or more processors coupled to the display and the one or more memory resources, the one or more processors to: receive a transport request for a transport service from a user, the transport request specifying at least one of a pick-up region or a drop-off region; determine one or more locations of interests within the at least one of the pick-up region or the drop-off region; compare the at least one of the pick-up region or the drop-off region with one or more historical locations related to the user; and determine a likely location based on the determined one or more locations of interest and the one or more historical locations.
 18. The mobile computing device of claim 17, wherein the one or more processors determine one or more locations of interests by referencing a business directory.
 19. The mobile computing device of claim 17, wherein the one or more historical locations related to the user includes at least one of one or more locations recently visited by the user, one or more locations commonly visited by the user, or one or more locations previously visited by the user that is closest to the at least one of the pick-up region or the drop-off region.
 20. The mobile computing device of claim 17, wherein the one or more processors further: in response to determining the likely location, provide a prompt on a user interface feature that asks the user whether the likely location is a location the user would like to be picked up at or dropped off at. 